Emergency Response Demo: Application Overview

In August 2017, Hurricane Harvey caused massive flooding in Southeast Texas, USA. The storm left a number of residents stranded and in need of rescue. Emergency first responders were overwhelmed with the high volume of rescue calls. A loose-knit group of volunteer boaters assisted in the rescue effort. These volunteers explored neighborhoods seeking out residents who needed assistance. In addition, with the support of social media, a group of volunteers served as dispatchers to relay rescue requests to the volunteer boaters. This group of volunteers became known as the Cajun Navy. The Cajun Navy has been operating in various forms since Hurricane Katrina in 2005.

The Emergency Response Demo application is inspired by the Cajun Navy response from Hurricane Harvey. It provides an online solution to connect stranded residents with volunteer responders. This application makes it easy to engage the community to organize volunteer responders.

The Mission Service exposes an API for managing Missions, including getting a list of mission keys, getting a specific mission by key, clearing all missions and getting missions assigned to a specific responder.

The Mission Service listens on Kafka to the topic-mission-command topic for details of new or updated missions being created. New Mission messages trigger a call to MapBox to generate the routes for a mission, using the responders location as a starting point, the victims location as a way point and the shelter location as the final destination. The mission details are then stored in JDG, to service API requests for Mission details.

The Mission Service sends updates to Kafka on the topic-mission-event topic in response to mission state change events such as when a mission is created, when an API request is received (e.g. to complete all missions). The Mission service also sends updates to Kafka on the topic-responder-command when missions are completed to indicate that the Responder is available for a new mission.

The Process Service is responsible for managing the overall process flow of the system. The Process Service operates purely on Kafka messages and does not expose any HTTP API - although it does invoke HTTP APIs in the Responder and Incident Priority Services.

When a new Incident is reported on the topic-incident-event Topic, the process Service kicks off a new BPM process to manage the new Incident. When a Responder is shown as available (via the topic-responder-event Topic), the BPM process is updated to reflect this. As the Mission progresses and additional messages are received on the topic-mission-event Topic, the BPM process is updated to reflect the latest state.

The Process Service sends out multiple types of messages on various Topics in response to the Incident progressing through the Business Process.

The Incident Service exposes an API for registering new Incidents and retrieving information about existing Incidents. An endpoint is also exposed for resetting Incident state (this is typically used by simulator services for managing and resetting the demo).

When a new Incident is received, the Incident details are stored in the database and a new message is sent out on the topic-incident-event Kafka Topic.

The Service also listens on Kafka to the topic topic-incident-command for updates to Incidents and stores the latest Incident state in the Database.

The Responder Service exposes an API for managing Responders, including registering new Responders, retrieving information about all available responders and retrieving information about specific responders. Endpoints are also exposed for removing responders and resetting responder state (these are typically used by simulator services for managing and resetting the demo).

When a new Responder is registered, the Responder details are stored in the database.

The Service also listens on Kafka to the topic test-topic for updates to Responders and stores the latest Responder state in the Database. If the update to the responder includes an Incident Id (i.e. if the responder has been assigned to work on an Incident) the services also sends a new Kafka message to the topic test-topic.

The emergency console is the front end UI for the Demo Solution. It provides the following main views:

The console communicates with several of the back end services (Incident, Mission & Responder) to display real time data via WebSockets.

The Responder Simulator is responsible for moving responders (both bots and humans) around the map during missions. As the demo requires the movement of personnel to function and since we can not have real people actually moving many miles for each Mission, this simulator is required to allow the demo to function.

The Responder simulator listens on the topic-mission-event for details of active responders that need to be moved on the map. The simulator them periodically updates (default every 10 seconds) the responders location (based on the mission route received) to show the responder at the next location. As the simulator moves responders, it emits messages on the topic-responder-location-update Topic.

The Disaster Simulator is used for managing / coordinating the demo. It exposes a basic UI which allows a user to add and remove Incidents and Responders in order to drive the demo forward.

The Disaster Simulator uses HTTP API requests to the Incident Service, the Responder Service the Mission Service and the Incident Priority Service in order to manage data creation / deletion.

When a Responder is assigned an Incident, a Mission is created. The Mission defines where the Responder needs to go to collect the victims of the Incident (the Way Point) and what shelter the victims should be dropped off at (the Target Location). The mission also has details of the responders location history.

An incident is a request for help from an individual (or group of individuals) that are in need of rescue. Details of an Incident include the location (Lat, Long), the number of people stranded and whether medical assistance is required.